PCM音频数据、DSD音频数据，spdif，以及DOP格式说明

https://blog.csdn.net/LINZAI508/article/details/111413061#commentBox

对苹果平台而言，既然它只支持PCM，因此我们想办法把DSD数据装进每一帧PCM数据里，并用它系统原生的usb驱动传输。DSD数据是1bit的，采样率为2.8224Mhz。换句话说其码率为2.8224Mbits/sec。这相当于16bit/176.4khz规格的PCM。为了能清楚的表示该PCM数据流里封装的到底是PCM还是DSD，我们还需额外的位来放一些标识信息。一般来讲比16/176.4规格还高一级的就是24/176.4了。也就是说我们多出来8位可用。虽然看起来有点多（如果我们能用01两种状态就够的话，8位能给出256种状态）。但实际上这8位都能派上用场，如图： 最前面的8位（Most Significant Bits，简称MSB）用作DSD标识，在每声道的每个PCM帧中以0x05和0xFA（16进制码，这种码每一位分别可对应二进制中的4位）两种形式交替出现（早先版本则使用0xAA）。这样做是为了防止解码器错把DSD数据认成PCM时爆出大量杂音，经上述设置，误读时会输出一个88khz但幅度低至-34db的声音。绝对无害且多数解码器内部在输出前就把他滤掉了（如果反过来，将PCM认成DSD的话，产生的杂音则不大好预测）。需要强调的是，软硬件厂商能用一些安全手段就轻易将上述隐患扼杀在设计阶段。这也是他们的责任：保证成品绝不出此类问题。经此文原作者验证，一种比较稳妥的，防止误判的办法是：传输的数据从PCM切换成DSD时，接收端至少检查32个连续的DSD标识符，每声道都要查！从DSD切换到PCM时，至少检测其中一个声道丢失的一个标识符。这样做会产生额外180微秒的延迟，但如果这时USB缓存没空且微帧（USB规范中对帧和微帧的划分和本主题关系不大，这里不再赘述，只需知道他和本身中PCM帧不是一个层面上的事）依然在被接收时，则不会产生延迟。当然，最好的办法还是让播放软件先验证下播放硬件能否支持DSD，然后再开始播放，验证的渠道也是多种多样的，通过物理层，驱动或OS都可做到。

图中后16位用来承载DSD数据，从t0开始装入。USB规范通常将每个PCM帧分配到一个特定声道上（比如左或右）。使用DoP模式时，被打包的DSD数据的声道，要与封装他的那个PCM帧被指派的声道一致。

上述情况都是针对DSD64而言，而对DSD128，由于码率增加一倍，相应的也需要PCM的采样率增加到352.8kHz，这里分两种情况：

用户的播放设备支持上述规格，那么从DSD64直接扩展到128即可，所有表示位和数据结构都保持不变。

设备不支持这种高规格（例如使用AES/EBU时），这时还有一种办法：

用原先一对PCM帧，比如分别存储左右声道的两帧凑来存一个声道的DSD128数据。不过把前16个DSD位和后16个DSD位拆开存在前后两帧里。同时这里要用与之前不同的标识符，如下图红框中所示：